[レポート]インサイトを最大限に活用してSnowflakeのクラウド費用を最小化する – Looker:JOIN 2019 at San Francisco #looker #JOINdata
現地時間2019年11月05日〜07日の期間、米国サンフランシスコで開催されたLookerの年次カンファレンスイベント『JOIN 2019』。今年2019年のイベントは、弊社から3名のメンバーが現地参戦しました。
当エントリでは、その中から『Maximizing Insights to Minimize Cloud Spend at Snowflake (インサイトを最大限に活用してSnowflakeのクラウド費用を最小化する)』の内容について参加レポートをお届けします。
目次
セッション概要
セッションの概要は以下の通りです。
Andrew Seitz氏(Snowflake社 Manager, Data & Analytics)
[セッション情報]:
Maximizing Insights to Minimize Cloud Spend at Snowflake
(インサイトを最大限に活用してSnowflakeのクラウド費用を最小化する)
Managing cloud spend is core to Snowflake’s business model. In addition to being costly, out-of-the-box SaaS solutions could not deliver a flexible enough product to work for our business. Join this session to learn how we built a streamlined solution that enables a seamless real-time view of our product's top and bottom lines—be it through easily consumable dashboards or robust functionality for deeper dives.
(クラウド費用の管理はSnowflakeのビジネスモデルの中核です。それを管理するための手段として、すぐに使用できるSaaSソリューションがありますが、それは高価であることに加えて、当社のビジネスで機能するのに十分な柔軟性のある製品を提供できませんでした。このセッションでは、簡単に利用できるダッシュボードや、より深いデータ分析に対応する堅牢な機能を通じて、製品の総収入と純利益をシームレスにリアルタイムで表示できる合理化されたソリューションの構築方法について説明します。)
セッションレポート
※セッションレポートの記述では、登壇者を一人称としています。
Snowflakeについて
Snowflakeはクラウド上に構築されたデータウェアハウスです。
このように、一元化されたストレージ層があります。このレイヤーでは、Snowflakeプラットフォーム内のすべてのデータに加えて、一元化されたストレージ層を囲むクラスタと、仮想ウェアハウスと呼ばれるコンピューティング・インスタンスが使用されます。これらの仮想ウェアハウスは、実際にクエリを実行するためのものであり、ワークロードに応じて任意のサイズに拡張/縮小できます。さらに、これらの仮想ウェアハウスは、並行して実行することもでき、組織が必要とする可能性のある同時並行性の量を把握できます。
また、同じ一元化されたストレージ層を提供できます。同じデータを同時に処理します。
しかし、実際にサービスで提供される主なコストは、これらのコンピュート自体であり、「年間数百万ドルでしか稼働していない感」を実感することができます。
さらに、Snowflakeは消費ベース(使った分だけ利用費を支払う)のビジネスモデルであるため、当社の収益は、Snowflakeの使用量に比例します。今年の売上の対前年比は3倍以上になり、今年も同じペースで進んでいます。
私たちは、3つの主要なパブリッククラウド全てで事業を展開していますが、その理由は複数あります。 これらの地域とアベイラビリティゾーンにはそれぞれ固有の使用パターンとそれに関連する変動コストがあります。したがって、高度な自動化を必要とする規模で運用するためです。今日のトピックはAWSを主として話しますが、それらは他のパブリッククラウドでも同様です。
パブリッククラウドの費用体系について
今日のセッションの準備段階として、クラウドの費用とその意味について簡単に紹介したいと思います。AWSの仮想コンピューティングには、さまざまなサイズと形状があります。 大量のRAMを必要とする大きなCPUが搭載されたものや、メモリを集中的に使用するもの、計算負荷の高いワークロード向けに最適化されたもの等があります。AWSは、インスタンスファミリーとインシデントサイズが用意されており、それぞれに応じてパフォーマンスが向上します。
また、AWSでは、これらのコンピューティングインスタンスに実際に支払う方法を選択することができ、それらは2つの主要なタイプに分類されます。
- オンデマンドインスタンス
- ご利用になった分だけお支払い。初期費用はかからない。
- リザーブドインスタンス
- 時間割引料金
- 割引率は30~75%
- 1年または3年の期間
- 1つの購入済みRI→期間全体で1時間あたり1つのサーバーインスタンス
右側のグラフを御覧ください。顧客の需要という点では、ここで最も重要なのはこのオレンジ色の線です。このオレンジ色の線はリザーブドです。これは、現在のリザーブドインスタンスを示します。オレンジ色のラインより上のものは、よりエキサイティングなオンデマンドインスタンスであり、オレンジ色のラインより下に行くと、リザーブドより安くなります。
このオレンジ色の線を効果的に設定するにはどうすればよいでしょうか
AWSへの事前コミットメント(先払い分の費用)を最小限に抑えながら、コスト削減を最大化したいですよね。このオレンジ色の線の設定が高すぎたり低すぎたりしないようにしたいですよね。
これはかなり新しい問題です。 この問題を解決できるソリューションは市場にあるでしょうか。一応、色々ありますが、これらはまだ「解決できる可能性」に着手しはじめた段階といえます。また、この問題に十分な時間やリソースを割けないスタートアップにいるかもしれません。
私たちは、パブリッククラウドのデータセットを探索し、さらに深く掘り下げる能力が必要であることがわかりました。また、このデータを社内の製品やサービスと結合する能力も必要でした。さらに、SaaSアプリケーションは、顧客のクラウド費用の一定の割合を請求しますが、その増加率は、顧客が回収する価値を大幅に上回っています。
Snowflake×Looker
市場に存在する既存のソリューションは、私達が必要としている規模と複雑さでは運用することができず、提供される価値よりも、コストの方が大幅に上回っていました。この問題に対処するには、カスタムされた分析ソリューションが必要でした。
私たちが見つけた解決策は、SnowflakeとLookerの組み合わせでした。私たちは、最上位の請求データを、商品やサービスとともに直接Snowflakeに取り込むことができます。
Snowflakeを計算エンジンとして使って、先ほど話した計算をします。Snowflakeの上にワーカーを重ねて前述した計算とやり取りするためのリアルタイムアクセスレイヤーとして機能し、これらのデータセットへのリアルタイムアクセスを提供することもできます。
この問題に取りかかる前に、いくつかの重要なデータセットを、Snowflake内部のデータウェアハウスに取り込む必要がありました。また、クラウドプロバイダー側のデータには、私たちが取り込む必要のある3つの主要なデータセットがありました。
- コストと使用率のデータ
- 時間単位
- インスタンス単位
- リザーブドインスタンスのポートフォリオ
- クラウドサービスの価格
リザーブドインスタンスプランナー
ここで、具体的にどのようにしてオレンジ色の線を設定するための計算を勝ち取るのかをお話ししましょう。これはリザーブドインスタンスプランナーと呼ばれるツール(オリジナルのツールではなく、前述のLookerとsnowflakeを組み合わせたソリューションのこと)を使い、特定の期間の複雑さを調べ、最大のコスト削減方法を知るために最適なカバレッジのレベルを調べます。
まず、さきほど話をしたデータソースのすべての履歴データを1つのテーブルにまとめる必要があります。次に、まとめたテーブルに対して線形最適化を実行します。これにより、購入するべきリザーブドインスタンスがわかります。 次に、この数値を取得してビジネスエンドユーザーに送り、プランナーが出した推奨事項を詳しく調べて、実際に購入するかどうかを判断してもらいます。
では、実際にクエリを作成し、すべてのデータを同じ場所にまとめます。ここでは、計算のために選んだ各AWSアカウントを見ていますが、これはSnowflake(が動いているAWS環境)のリージョンやインスタンスファミリーに相当します。
次に、オンデマンドインスタンスとリザーブドインスタンスで費やした金額の内訳を計算します。この場合、リザーブドインスタンスのワークロードは一定です。
さらに、各期間のオンデマンドレートとリザーブドレート、アカウントの組み合わせを取り込みます。全てのデータを1つの場所に集めたら、線形最適化を実行して、過去の使用期間を調べます。そして、1時間ごとに、その時間内に異なるレベルのリザーブドインスタンスカバレッジがあるかどうかを分析します。
これらのシナリオのそれぞれで、どのようなコスト削減が可能になるのでしょうか。この質問を自分自身に問いかけました。まず、リザーブドインスタンスの購入を最低限にしたい場合は、リザーブド「0個」を追加購入します。現在のカバレッジが上限である場合、計算を実行する期間を調べます。そして、インスタンスの数が最も多いものを見つけます。
この例では、最大稼働時間が10であるかどうかを調べます。この期間の最大稼働時間は15です。
次に、この数と、購入可能なリザーブドインスタンス(0~5)との差を計算し、これを使用してリザーブドインスタンスの有効購入数を計算します。つまり、セル内に書いてあるのはリザーブドインスタンスを仮説に基づいて購入した数ということです。
次に、コストとそれぞれのシナリオを計算します。一番上の行では、営業時間の10%、さらに安くできることがわかります。すばらしいですね。それに加えて、プラス5時間では、倍も高いオンデマンドレートであることもわかります。一番下の行は、完全なリザーブドインスタンスのカバレッジと考えられるものがあります。
次に、仮説上のリザーブドインスタンス数でグループを作成し、この計算を実行している期間全体のコストを計算します。これは、コストが最小の場合のリザーブドインスタンスの数です。コストでソートして、コストが最も低いものを推奨するならば、この場合、すべてのシナリオで、この期間のコストが最も低くなります。
実際にはどのように見えるのでしょうか?そこで、テンプレートフィルタを利用して、ビジネスエンドユーザーがこのクエリを構成し、どの地域で、どの期間に計算を実行するか等をリアルタイムでファクタリングできるようにします。過去14日分を調べるかどうか、過去および将来の期間を調べるかどうかを計算します。他にもスライドにあるようなフィルタを提供しています。
実際にクエリを実行してみました。これらのシナリオでは、何を購入すべきか、どのようなコスト削減が可能かについて推奨事項を提示します。
先ほど言ったように、私たちはこの推薦を盲目的に信じることをしません。したがって、ビジネスエンドユーザーがこの計算をさらに深く理解できるようにするには、2つの方法があります。1つ目は、いわゆる利用曲線です。これは先ほど話したオレンジ色の線で視覚化した線と非常に似ています。また、計算のために選択した期間におけるインスタンスの使用状況が表示されます。
このデータセットに視覚的な異常があった場合、これを使用して、推奨事項が適切か不適切かをデバッグできます。このような異常の例としては、エンジニアリングチームが大規模なデータセットに対して埋戻しを実行した場合や、単発の問題をデバッグしている場合などがあります。
次に、エンジニアリング・チームとのコミュニケーションして、これが1回限りのワークロードなのか、それとも実際に繰り返し発生するものなのかを判断します。これで、リザーブドインスタンスを購入するように設計された会話を使用できます。
次に、曲線を見てみましょう。割引曲線は、(RIを)購入した場合にセーブできる金額の量を示しています。これはさっき話した計算結果を視覚的に表したものです。私たちが提案しているのは、実はこの放物線の頂点であり、最もコスト削減できるポイントです。しかし、もし私たちが非常にフラットな割引曲線を持っているなら、それは異なるレベルのコミットメントを意味します。
まとめ
これらの施策はビジネスにどのような影響があったのでしょうか。
まず第一に、独自のソリューションを構築し、クラウドのコストを、年間で2~3%削減できたと見積もっています。 また、今までは、これらの問題を修正したりするのに4~6ヶ月だったことが判明しました。そして、今回の社内ソリューションを使用することで、1時間以内にこれらすべてに対応できるようになりました。
先程お話した計算の手動ステップの一部は、今、可能な限り自動化しようとしています。しかし、ビジネスに還元される真の価値は、Snowflakeのビジネスに不可欠な、この機能のための社内の専門知識を構築できることです。そして、顧客にとって、より効果的で、コストパフォーマンスの高いサービスを提供することが求められています。これは、私のチームがSnowflakeとLookerの両方を使って、クラウドファイナンスで着手した多くのプロジェクトの1つにすぎません。
本日はご出席いただきありがとうございました。
セッションを聴講して
良かったところ
Lookerと相性が良いDWHといわれているSnowflakeですが、そのSnowflake社自身が、Snowflake自身のクラウド利用費を抑えるための分析にLookerを使っているという面白い内容でした。
気になっているところとしては、具体的なLookMLやダッシュボードの画像をもっと見たかったです。